Replaces the placeholder costing of multiIndexArray with a benchmarked model: CPU linear in the number of indices (linear_in_y), memory linear in the length of the result. The denotation forces each element read eagerly, as indexArray does, so the array access is paid for inside this builtin rather than wherever the element is later demanded. Resolves IntersectMBO/plutus-private#2259.

The number of indices is limited to 4096, because beyond that the execution time is not predictable from the index count alone. This is the same kind of limit, for the same kind of reason, as the ones on integerToByteString and replicateByte; see Note [Index count limitation for multiIndexArray]. It is far above any realistic use, since a 16384-byte transaction could not carry that many serialised indices even if it carried nothing else. It does need a CIP-0156 amendment, and it is much cheaper to add now than once the builtin is deployed.

Benchmarks cross log-spaced array sizes from 1 to 131072 with index counts from 1 to the limit, using uniformly random indices, plus off-grid points and two control cells with 1 KiB elements. Neither array size nor element size affects the cost. The index lists are deliberately given unfavourable spacing, described in Note [Scattered index lists], because a list built the obvious way gets favourable spacing and fitting to that would understate the cost. A few inputs, including the largest index count, are spaced as widely as a transaction's memory budget would allow, since the fit takes the slowest observation at each end of the range.

The slope and intercept come from a line through the ends of the benchmarked range rather than from least squares. Per-index time rises slightly with the index count, and least squares on such data returns a negative intercept, which adjustModel then clamps, discarding the fixed cost of a call along with it. The fit is checked against every data point, and as a sanity check on the outcome a single-index multiIndexArray is charged 311,081 ps against indexArray's 232,010, which is the right ordering because it does strictly more work.

ParamName entries for the four new parameters are appended to V1, V2 and V3, following the batch-6 precedent. A new page under doc/cost-models/multiindexarray plots the benchmark data against the model. Fitting the model locally requires working around the EqualsByteString off-diagonal data gap in models.R (see #7868).